Real-time communications using a restlike api

ABSTRACT

A computing device executes a client-side instance of an application that supports bi-directional real-time synchronous communication and real-time asynchronous communication with a server computing device by way of an application programming interface (API) that conforms to representative state transfer (RESTlike) design principles. An eventing framework on the server computing device is used to aggregate updates to resources on the server that are requested by the client computing device, and is further used to transmit metadata to the client computing device that indicates which updates are available. Real-time sensitive updates are included in the metadata, and the client computing device can decide when and how to retrieve other available updates. An asynchronous operation is modeled on the server computing device by an operation resource that can modify other resources on the server computing device and cause updates regarding status of the operation to be sent to the client computing device.

RELATED APPLICATION

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/771,073, filed Feb. 28, 2013, and entitled “UNIFIEDCOMMUNICATIONS TECHNOLOGIES,” the entirety of which is incorporatedherein by reference.

BACKGROUND

Computer-implemented Unified Communications (UC) applications enableusers thereof to receive and transmit real-time communications by way ofa plurality of differing communications modalities. For instance, anexemplary UC application can be configured to support instant messaging,voice communications, teleconferencing, video conferencing, voicemailretrieval, calendar syncing, and content sharing, amongst othercommunications modalities.

Traditionally, signaling of endpoints with client-side instances of a UCapplication installed thereon has been powered by dedicated,proprietary, and standard protocols (session-based, command and control,or hop-by-hop), such as SIMPLE, SIP, H.323, XMPP, Jingle, Skinny, andthe like. Each of these protocols has been fine-tuned to address arespective aspect of communications supported by the UC application; forexample, a first protocol can be employed for telephone call set-up, asecond protocol can be employed for setting or subscribing to presenceof an individual, etc. A consequence of this approach is thatclient-side instances of conventional UC applications are relativelycomplex, as core logic is pushed to such client-side instances (referredto herein as “clients”). Effectively, then, clients act as respectivecoordination points of various signaling flows—if a client is unable tosupport a certain protocol, it may not be considered by users to be afull-fledged UC application. In an example, conventional web-basedclients support instant messaging and presence, but not enterprise-widevoice and video communications, and thus may not be considered afull-fledged UC application by users.

Several deficiencies are associated with conventional UC applicationsdue to the architecture described above. First, evolution oflight-weight clients is difficult, as remote procedure call protocolsare relatively inflexible to change, as such protocols force an explicitor implicit coupling (tight coupling) between clients and correspondingcode executing on servers. Thus, if new features are added to the UCapplication, legacy clients may become inoperable. Further, theconventional approach is associated with a high memory footprint,chattiness, and high bandwidth utilization. A Remote Procedure Protocol(RPC) adopted to power conventional web-based clients in UC applicationscan cause server-side code (referred to herein as “servers”) to oftensynchronize 100% of a client state, even when a user interface of theclient needs a relatively small amount of information. Moreover, suchapproach is associated with a lack of standard/monitoring tools, as theabove-noted RPC employs the hypertext transfer protocol (HTTP) as atransport layer, with one Unified Resource Locator (URL) representingthe service—this results in a lack of standard tools to monitor healthof the UC application.

SUMMARY

The following is a brief summary of subject matter that is described ingreater detail herein. This summary is not intended to be limiting as tothe scope of the claims.

Various technologies pertaining to an application programming interface(API) that generally complies with a representational state transfer(REST) architecture are described herein. Such an API, when employed bya UC application, provides support for synchronous communications (e.g.,Voice-Over-IP (VoIP), video conferencing, application sharing, datacollaboration, . . . ). Additionally, the UC application can alsosupport asynchronous communications (e.g., online meeting scheduling,presence, and synchronizing contacts and group information, . . . ).Additionally, the UC application utilizing the API described herein canfacilitate asynchronous and synchronous communications in real-time (onthe order of milliseconds or less).

In an exemplary embodiment, such application can be a unifiedcommunications (UC) application. A system architecture that supportssuch an application includes client computing devices in communicationwith server computing devices, where the client computing devicesexecute client-side instances of the application (clients) and theserver computing devices execute server-side code (servers). The clientcomputing devices may include desktop computing devices as well asportable computing devices such as mobile telephones, tablets (slates),phablets, wearables, etc. In accordance with aspects described herein,real-time synchronous and asynchronous communications between clientsand/or between a client and a server can be accomplished throughemployment of an API that conforms to the REST architecture (e.g., aRESTlike API).

The API is modeled in terms of identifiers and commands, where theidentifiers represent resources and the commands represent methods ofinteracting with resources, such as conventionalhypertext-transfer-protocol (HTTP) methods. The UC application cantransmit data by way of the API using a variety of payload formats, suchas conventional hypermedia types. A resource can be or include data,such as a document, image, database entry, etc. In another example, aresource can be or include computer-executable code, such as a service,an executable thread, etc. Furthermore, resources generally pertain to aparticular concept described by their respective identifiers. Forexample, a “contacts” resource can include a list of contacts of a user,or can be a service that retrieves the list of contacts from otherresources. Each resource is identified by a respective globalidentifier, such as a universal resource locator (URL) that can be usedby the client to access a respective resource. Resources can alsocomprise global identifiers of other resources, so as to indicate alink-relation. For example, the “contacts” resource can also comprise aglobal identifier of a “profile” resource that comprises a profile of acontact of the user. The client, after accessing the “contacts” resourceand locating the global identifier for the “profile” resource, can thenuse the global identifier for the “profile” resource to retrieve theprofile of the contact. Such link-relations can allow a client tonavigate through resources in a manner that is similar to how a user cannavigate through webpages using hyperlinks.

Thus, an exemplary APIs employed by a UC application can uselink-relations to express capabilities supported by the UC application,wherein the use of link-relations conforms to the HATEOAS (Hypertext asthe engine of application state) principle. New capabilities can beintroduced by adding new link-relations.

As noted above, the commands represent respective methods of interactingwith resources. Exemplary methods include retrieving data from aresource, adding data to a resource, replacing or adding a resource, anddeleting a resource. By combining an identifier and a command in arequest, a client can indicate a resource that is desirably accessed aswell as an operation that is desirably executed. For example, in orderto retrieve a list of contacts of a user, a client can generate arequest that includes a command representing a retrieval operation andan identifier representing the “contacts” resource.

It may be desirable, however, to add, modify, or delete resourcessupported by the server, and accordingly it may be desirable to updateclients. Thus, in an example, a client can send a “hanging request” tothe server for events (e.g., a listing of updates to resources), where ahanging request is one to which the server need not immediately reply.For example, rather than replying that no new updates to resources usedby the client are available, the server can wait until an update occursto generate/transmit a reply.

The server can additionally leverage an eventing framework to aggregateevents and updates to resources on the server and determine how and whennotifications of such updates are delivered to the client. Rather thansending all such updates, e.g., synching 100% of the state, the servercan transmit metadata to the client that describes updates that areavailable, and the client can request desired updates. In an exemplaryembodiment, the server can assign each event/update a category, whereinexemplary categories include real-time sensitive, high urgency, and lowurgency.

When an update is real-time sensitive, the server can embed the updateinto the metadata transmitted to the client, allowing the client toreceive the real-time sensitive update without having to determine thatthe update is needed, make a request to the server, and wait for theupdate to be received, thereby reducing latency for delivering real-timesensitive updates. High urgency updates can be indicated in themetadata, and the client can choose when to request delivery of suchupdates from the server. Updates can be retrieved eagerly (e.g.,relatively quickly), lazily (when convenient or when a cost ofretrieving the update is below a threshold), or an update may beignored. Low urgency updates can be aggregated and withheld by theserver until either a predetermined time period has passed (e.g., untilthe hanging request expires) or until the low-urgency update becomes ofhigher urgency. With respect to early retrieved updates, provision of ahigh urgency update can be delayed for a relatively short period of time(e.g., on the order of 50 ms) to allow for aggregation of high urgencyupdates.

Further, an application can incorporate an asynchronous operation,wherein one or more endpoints and/or a server need not operateconcurrently. For example, in electronic messaging, a receiver need notbe active for a sender to send a message. An asynchronous operation maybe initiated by a client, such as a sender desiring to send a message,or by a server, such as when the server desires to deliver updates tofiles that are shared between multiple clients working asynchronously.Because portions of the asynchronous operation may occur at differentlocations (e.g., at the client or server), and because such portions mayoccur at different times, a resource may persist on the server after aclient's request has been completed. In a conventional (e.g., stateless)REST architecture, the persisting resource may not be served to theclient in a subsequent request However, by leveraging the RESTlike API,the client, by requesting to perform such the asynchronous operation,can cause the server to create an operational resource that can keepsthe client updated as to the progress of the asynchronous operationwhile still respecting the HATEOAS principle.

The above summary presents a simplified summary in order to provide abasic understanding of some aspects of the systems and/or methodsdiscussed herein. This summary is not an extensive overview of thesystems and/or methods discussed herein. It is not intended to identifykey/critical elements or to delineate the scope of such systems and/ormethods. Its sole purpose is to present some concepts in a simplifiedform as a prelude to the more detailed description that is presentedlater.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 are functional block diagrams of respective exemplarysystems that facilitate executing an application that supportsbi-directional real-time synchronous communication through use of aRESTlike API while also supporting asynchronous communication.

FIG. 3 is a functional block diagram of an exemplary system thatfacilitates executing an application that supports an asynchronousoperation through use of a RESTlike API.

FIGS. 4-9 are flow diagrams that illustrate respective exemplarymethodologies for bi-directional real-time asynchronous and synchronouscommunication through use of a RESTlike API.

FIG. 10 is flow diagram that illustrates an exemplary methodology forbi-directional communications for an asynchronous operation through useof a RESTlike API.

FIG. 11 is an exemplary computing system.

DETAILED DESCRIPTION

Various technologies pertaining to real-time communications betweencomputing devices through use of an API that conforms torepresentational state transfer (REST) architecture are now describedwith reference to the drawings, wherein like reference numerals are usedto refer to like elements throughout. In the following description, forpurposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of one or more aspects. It maybe evident, however, that such aspect(s) may be practiced without thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form in order to facilitate describing one ormore aspects. Further, it is to be understood that functionality that isdescribed as being carried out by certain system components may beperformed by multiple components. Similarly, for instance, a componentmay be configured to perform functionality that is described as beingcarried out by multiple components.

Moreover, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom the context, the phrase “X employs A or B” is intended to mean anyof the natural inclusive permutations. That is, the phrase “X employs Aor B” is satisfied by any of the following instances: X employs A; Xemploys B; or X employs both A and B. In addition, the articles “a” and“an” as used in this application and the appended claims shouldgenerally be construed to mean “one or more” unless specified otherwiseor clear from the context to be directed to a singular form.

Further, as used herein, the terms “component” and “system” are intendedto encompass computer-readable data storage that is configured withcomputer-executable instructions that cause certain functionality to beperformed when executed by a processor. The computer-executableinstructions may include a routine, a function, or the like. It is alsoto be understood that a component or system may be localized on a singledevice or distributed across several devices. Further, as used herein,the term “exemplary” is intended to mean serving as an illustration orexample of something, and is not intended to indicate a preference.

With reference now to FIG. 1, an exemplary system 100 that facilitatesreal-time synchronous and asynchronous communications between computingdevices is illustrated. The system 100 includes a plurality of clientcomputing devices 102-104. The client computing devices 102-104 caninclude desktop computing devices, laptop computing devices, netbooks,ultrabooks, tablets (slates), phablets, mobile telephones, etc. Thesystem 100 further includes a server computing device 106, which is incommunication with the client computing devices 102-104 by way ofsuitable respective network connections. Additionally, communicationschannels can be established directly between computing devices in theclient computing devices 102-104 to facilitate communicationstherebetween.

The client computing devices 102-104 and the server computing device 106are configured to support synchronous and asynchronous real-timecommunications therebetween by way of a communications applicationdistributed between the client computing devices 102-104 and the servercomponent device 106. With more particularity, the first computingdevice 102 includes a first processor module 108 that executesinstructions retained in a first memory 110. The first memory 110 caninclude a first client-side instance of a communications application,referred to as a first client 112. Similarly, the Nth computing device104 can include an Nth processor module 114 that is configured toexecute instructions in an Nth memory 116. The Nth memory 116 includesan Nth client-side instance of the communications application, referredto as an Nth client 118.

While the server computing device 106 is depicted as a single device inFIG. 1, the server computing device 106 may be a plurality of servercomputing devices (e.g., a distributed server) and may be or compriseone or more virtual machines. The server computing device 106 includes aserver processor module 120 that is configured to execute code in aserver-side memory 122. For example, the server-side memory 122 caninclude server-side code of the communications application, wherein theserver-side code is configured to support at least one communicationsmodality of the communications application. The server-side code isreferred to herein as a server 124. For example, the server 124 cansupport instant messaging between client computing devices, maintenanceand provision of presence information to client computing devices, etc.

The communications application distributed between the client computingdevices 102-104 and the server component device 106 can supportreal-time asynchronous communications and real-time synchronouscommunications between computing devices. Real-time asynchronouscommunication refers to transmittal of data to a recipient device (e.g.,one of the client computing devices 102-104) at times or intervals thatare unknown to the recipient device. For example, an asynchronouscommunication can be at least one of a file transfer, an electronicmessage (e.g., email, instant message, . . . ), an event schedulingrequest, a presence indication, an update to a list of contacts orgroups, etc. Synchronous communication refers to when both a sender andrecipient are communicating and are synchronized with one another,although in some instances synchronization may be approximate. Forexample, synchronous communication can include video streaming, videoconferencing, voice communication, application sharing between computingdevices, desktop sharing, etc.

In an exemplary embodiment, the communications application distributedbetween the client computing devices 102-104 and the server computingdevice 106 can be a unified communications (UC) application thatsupports multiple communications modalities, including at least one ofthe synchronous and asynchronous modalities referenced above. In anotherexample, the communications application can be or be included in asocial networking application that supports instant messaging, presence,and groups. In still yet another example, such communicationsapplication can be an instant messaging application that supportsinstant messaging, presence, and voice communications. Other types ofcommunications applications are also contemplated.

The clients 112-118 and the server 124 can use a RESTlike API tocommunicate synchronously in real-time. To that end, the client 112 cancause a graphical user interface (GUI) to be displayed that includes,for example, contacts for a user of the client 112, messages received bythe client 112, etc. The server 124 can access, for example, a listingof contacts of the user, messages sent and received via the client 112,and other data in order to, for example, populate the user interface.When, for instance, the user of the first client computing device 102seeks to send a communication to a contact (e.g., the user of the Nthclient computing device 104), the first client 112 can communicate withthe Nth client 118 via the server 124 or via a channel established bythe server 124. The server 124, in addition to routing thecommunication, can also send other information to the first client 112,such as that the contact is available to communicate in real-time.

As will be described in greater detail herein, the RESTlike API ismodeled in terms of identifiers and commands, where the identifiersrepresent resources stored in the server memory 122, and the commandsrepresent methods of interacting with resources, such as conventionalhypertext-transfer-protocol (HTTP) methods and hypermedia types. Aresource can be or include data, such as a document, an image, etc.Additionally, a resource can be or include a computer-executable serviceor other computer-executable instructions. Further, a resource can be orinclude a combination of data and computer-executable instructions.Additionally, each resource can be directed towards a respective conceptdescribed by its identifier. For example, a “contacts” resource caninclude a list of contacts of a user. Each resource is identified by arespective global identifier, such as a universal resource locator (URL)that can be used by the client to access a respective resource. Aresource can also comprise a global identifier of other another resource(or multiple resources), so as to indicate a link-relation between theresource and the another resource. For example, the “contacts” resourcecan also comprise a global identifier of a “profile” resource, whereinthe profile resource comprises a profile of a contact of the user. Thefirst client 112, after accessing the “contacts” resource (e.g., fromthe server 124) and locating the global identifier for the “profile”resource therein, can then use the global identifier for the “profile”resource to access the profile of the contact. Such link-relations canallow the first client 112 to navigate through resources in a mannerthat is similar to how a user can navigate through webpages usinghyperlinks. Additional detail pertaining to the RESTlike API is setforth below.

Referring now to FIG. 2, an exemplary system 200 that facilitatesreal-time synchronous and real-time asynchronous bi-directionalcommunication (e.g., between a client and server or a client and client)through utilization of a RESTlike API is illustrated. The system 200comprises the first client 112 that is in communication with the server124 through utilization of the RESTlike API. In an alternativeembodiment, the server 124 can be replaced with the Nth client 118, suchthat the first client 112 and the Nth client 118 are in directcommunication with one another. The RESTlike API, as noted above, ismodeled using identifiers and commands. Such identifiers and commandscan be universal, in that they may be used without regard to a specificapplication being executed, a specific device being communicated with,or a specific operation being undertaken, and thus provide a generalizedinterface between devices.

Resources corresponding to the RESTlike API are now described. As shown,the server 124 can comprise or have access to a plurality of resources(e.g., a first resource 202 through an Mth resource 204). The format ofa resource is arbitrary, as a resource can be structured as a database,a file, etc. Identifiers can respective represent the resources 202-204,wherein a resource can comprise at least one of data (such as adocument, an image, a database entry or entries, etc.),computer-executable code, and the like. Each resource pertains to arespective concept (e.g., which can described by an identifier for theresource). For example the first resource 202 can be a “contacts”resource, and thus may comprise a listing of contacts of a user of thefirst client computing device 102 that includes the first client 112.Each resource is identified by a respective global identifier, wherein aglobal identifier can be a universal resource locator (URL) that can beused by the first client 112 to access the resource on the server 124corresponding to the global identifier. For instance, a globalidentifier for the first resource 202 can be as follows:

-   -   /messagingapp/user/contacts

A resource can also comprise global identifier(s) of other resource(s),so as to indicate a link-relation to the other resource(s). For example,the first resource 202 can comprise a global identifier for the Mthresource 204, wherein the Mth resource 204 is a “profile” resource andcomprises a profile of a contact included in the “contacts” resource.Thus, for instance, the first resource 202 can comprise a database entryrelating a contact of the user of the first client 112 (e.g.,“Contactl”) with a global identifier of the Mth resource 204, whereinthe Mth resource comprises the profile of Contactl, as shown in thefollowing example:

Contacts Profiles Contact1 /messagingapp/contact1/profile

The resources 202-204 can include a variety of different types ofresources, including but not limited to a dynamic resource, an operationresource, a sender resource, an event resource, a capability resource, acontainer resource, an operation factory resource, a dynamic containerresource, and/or a resource that combines aspects of the aforementionedresources. A dynamic resource is one that is likely to change or beupdated often, such as a presence indictor for a contact; an operationalresource represents an asynchronous operation; a sender resource isconfigured to report updates for a group of dynamic and operationresources; an event resource comprises a batch or listing of updatesgrouped by sender; a capability resource represents a capability of aparticular client; a container resource comprises resources of othertypes; an operation factory resource is a resource that can primarily beused to initiate an operation resource; a dynamic container resourcecomprises other resources and can generate an event when a resource isinserted, modified, or changed. It is also to be understood that aresource can comprise or combine features of the aforementioned types ofresources. For instance, an operation resource may also act as a senderresource and send updates.

Methods supported by the RESTlike API (represented by commands) forinteracting with resources are now described. Exemplary methodssupported by the RESTlike API include conventionalhypertext-transfer-protocol (HTTP) methods and hypermedia types. Thus,with more specificity, exemplary methods include a method for retrievingdata from a resource (e.g., via a “GET” command), a method for addingdata to a resource (e.g., via a “POST” command), a method for replacingor adding a resource (e.g., via a “PUT” command), and a method fordeleting a resource (e.g., via a “DELETE” command). The first client 112can generate a request that includes an identifier and a command,thereby identifying a resource desirably accessed and a method to beexecuted in connection with the resource. Accordingly, the first client112 comprises a requester component 206 that is configured to access aresource in the resources 202-204 by sending a request to the server 124that comprises an identification of a method (such as a method forretrieving data from a method) and an identification of a globalidentifier of the resource that is desirably accessed.

For example, the requester component 206, in order to retrieve the listof contacts from the “contacts” resource, can set forth the followingrequest:

-   -   GET/messagingapp/user/contacts        where “GET” identifies the method for retrieving data, and        /messagingapp/user/contacts is a global identifier that        identifies the first resource 202. Thus, rather than having to        store a contacts list locally, the first client 112 can request        content of the first resource 202 of the server 124. Using        global identifiers and methods allows the first client 112 to        make requests for a resource without having to have any        knowledge as to how the resource is stored on the server        computing device 106 or the way in which the server 124        implements the requested method.

Responsive to receiving the request for the first resource 202 from thefirst client 112, the server 124 can transmit the first resource 202 tothe client 112. In another example, the server 124 can generate a datapacket based upon content of the first resource 202 and transmit suchdata packet to the first client 112. For example, such data packet maybe smaller in size when compared to the first resource 202 itself.Additionally, the data packet may be in a format that is more readilyparsed by the first client 112 when compared to the format of the firstresource 202. In another example, where a resource is a service orcomprises executable code, the data packet can comprise data thatrepresents the service or executable code. Additionally, the data packetcan be in a format that is recognizable to the client.

Accordingly, rather than returning the first resource 202 identified inthe request set forth by the requester component 206, the server 124 cangenerate and return a data packet based upon content of the firstresource 202, wherein such data packet can be or include a document, alisting, or the like, and may be in a structured file format such as amarkup file (e.g., XML) or an object notation file (e.g., JSON). Forexample, a data packet that can be generated by the server 124 basedupon a resource can be a JSON representation of a database that includesa contacts list, such as follows:

  var ContactsList = [  {“name”: “Contact1”, “profile”:“/messagingapp/contact1/profile.”} ]

The first client 112 further comprises a receiver component 208 thatreceives data transmitted to the first client 112 from the server 124,such as the first resource 202 or the data packet based thereon, whichcan be stored in a cache that is accessible to the first client 112.

In an exemplary embodiment, as indicated above, the first resource 202include a list of contacts of a user of the first client 112, and canfurther include a global identifier of the Mth resource 204, where theMth resource 204 includes a profile of a contact in the list of contactsof the first resource 202. Thus, responsive to receiving the firstresource 202 or a data packet corresponding thereto, the first client112 can identify the global identifier of the Mth resource. Therequester component 206 can then transmit a request to retrieve the Mthresource 204 (or data included therein) from the server 124 (e.g., usingthe “GET” command and the global identifier for the Mth resource 204).Effectively, then, the first resource 202 is linked to the Mth resource204 via a link-relation. Link-relations between the resources 202-204allow the first client 112 to navigate through resources similarly tohow a user can navigate through web pages using hyperlinks.

The first resource 202 (including the list of contacts of the user ofthe first client 112) may not exist prior to the server 124 receivingthe request for such first resource 202. In such a case, the server 124can gather data needed to generate the first resource 202 responsive toreceiving the request, and can thereafter transmit the first resource202 (or a corresponding data packet) to the first client 112. It is tobe understood, however, that the first client 112 need not haveknowledge of how/when requested resources are generated, as the RESTlikeAPI provides a generalized interface between the first client 112 andthe server 124. Therefore, the first client 112 and the server 124 canbe deemed to be loosely coupled, in that the first client 112 and theserver 124 need not have specific knowledge of the components or methodsexecuted by the other.

The RESTlike API employed by the first client 112 and the server 124 canfacilitate updating of the first client 112 with additionalfunctionality (or reduced functionality). For example, a service orinformation offered by the server 124 may be desirably updated, and itmay be further desirable to provide such updates to the first client112.

For example, the communications application may be updated with a newfeature that provides a user with a list of contacts and location dataof each contact in the list of contacts. Thus, the first resource 202,which in this example comprises the list of contacts of the user of thefirst client 112, can be modified to include a global identifier of anIth resource (not shown) in the plurality of resources 202-204. Thefirst client 112 can ignore the new link-relation, and thus the requestset forth by the first client 112 for the first resource 202 remainsvalid. Therefore, the first resource 202 can be modified withoutimpacting the behavior of the first client 112. In a particular example,the first resource 202 can be modified to comprise the following:

Con- tacts Profiles Location Data Con- /messagingapp/contact1/profile./messagingapp/contact1/location. tact1The server 124 can generate a data packet based upon the first resource202 as follows:

  var ContactsList = [  {   “name”: “Contact1”,   “profile”:“/messagingapp/contact1/profile”,   “location”:“/messagingapp/contact1/location”  }

Continuing with this example, the Mth resource 204 is identified by theglobal identifier messagingapp/contactl/profile.html, and a request forsuch Mth resource 204 remains valid. Therefore, the update on the server124 need not affect the behavior of the first client 112.

Likewise, the first client 112 can be updated to account for changes toresources without affecting operation of the server 124. For instance,the first client 112 can be updated to contemplate the global identifierfor the Ith resource, such that the requester component 206 transmits arequest for the Ith resource upon the client 112 parsing the firstresource 202 (or a data packet corresponding thereto).

Detecting these types of updates may, for example, comprise navigatingthrough global identifiers of resources, constructing a map or graphbased upon the navigating, and comparing the map or graph to a previousmap or graph. The first client 112 can navigate through the globalidentifiers in the first resource 202, such as the global identifiers ofthe Ith resource and Mth resource 204, and can similarly navigatethrough any global identifiers comprised by the Ith resource and Mthresource 204. Such navigation can be repeated for additional resourcesidentified by additional global identifiers. The navigation through suchglobal identifiers can then be mapped or graphed, and the map or graphcan be compared to a previous map or graph in order to detect changes.

Updates to the client 112 and/or the server 124 need not be implementedin a particular sequence or at a particular time, as the RESTlike APIhas high forwards and backwards compatibility between clients andservers. Thus, functionality supported by clients and servers in thedistributed communications application can evolve independently withoutbreaking or becoming unusable together. This type of behavior isparticularly well-suited for relatively large distributed architectures,where it is not possible to redeploy an entire programming environmentevery time supported functionality changes.

Additionally, the resources 202-204 on the server 124 may be modified orchanged. In an example, the first client 112 can request a resource fromthe server 124, and the server 124 can generate a respective responseeach time a request from the first client 112 is received. Frequentrequests, however, can negatively impact real-time communications.Accordingly, an eventing framework can be used in connection withdetermining when and how the first client 112 is informed about updatesto respective resources, as well as when and how such updates aredelivered from the server 124 to the first client 112. To that end, thefirst client 112 can comprise an update requester component 210 that isconfigured to transmit a request to the server 124 that is configured toretrieve identifications of available updates to one or more of theresources 202-204. In an example, the server 124 can comprise or haveaccess to an event resource 212, which is configured to cause the server124 to identify categories assigned to updates and transmit identitiesof updates (or updates themselves) to the first client 112. For example,categories that can be assigned to updates can 1) include real-timesensitive; 2) high priority; or 3) low priority. As will be described ingreater detail below, the event resource 212 can cause the server 124 toimmediately transmit real-time sensitive updates to the first client112, can cause the server 124 to immediately notify the first client 112of an available high priority update, and can cause the server 124 tonotify the first client 112 of available low priority updates when anyone of 1) a real-time sensitive update is identified; 2) a high priorityupdate is identified; or 3) the hanging request for the event resource212 expires (e.g., 30 seconds, 45 seconds, 60 seconds).

Use of hanging requests reduces chattiness in communications between thefirst client 112 and the server 124, as replies from the server 124 tothe first client 112 will be less frequent. The update requestercomponent 210 can be configured to transmit hanging requestsperiodically or upon receipt of a reply to a hanging request (e.g., suchthat at least one request for the event resource 212 is always activewhen the first client 112 is being executed.

As noted above, the server 124 can assign a respective category to eachupdate identified in the event resource 212, where categories includereal-time sensitive, high urgency, or low urgency. When the eventresource 212 identifies an update that is assigned a real-time sensitivecategory, the server 124 can immediately generate a reply to the hangingrequest from the first client 112, wherein the update is included in thereply. Responsive to the receiver component 208 of the first client 112receiving the reply, the update requester component 210 can transmitanother hanging request (e.g., a hanging GET) for the event resource 212to the server 124. Accordingly, real-time sensitive updates to resourcesare received at the first client 112 in real-time, as such updates areidentified at the server 124. Additionally, responsive to a high urgencyupdate being identified in the event resource 212, the server 124 cangenerate a reply to the hanging request received from the first client112, where the high urgency update is identified to the first client 112in the reply, but the update itself is not included in the reply. Thefirst client 112, responsive to receiving the identification of the highurgency update, can request the update from the server 124 (e.g., wherethe request identifies the resource to be updated). For updatescategorized as being low urgency, the event resource 212 can aggregatesuch updates, wherein the server 124 transmit a reply to a hangingrequest when the hanging request expires or when a low urgency update ischanged to a high urgency update. The reply generated by the server 124identifies available updates, but does not include the updates in thereply.

With more specificity, as indicated above, available updates to one ofmore of the resources 202-204 (e.g., low urgency updates) can beaggregated in the events resource 212. Thus, when one of the resources202-204 is updated, the server 124 causes information pertaining to suchan update to be included in the events resource 212. Exemplary updatesto the resources 202-204 include addition of a resource to the resources202-204, modification of data in a resource of the resources 202-204(e.g., relative to a prior state of the resource), deletion of aresource from the resources 202-204, etc. Thus, if the first resource202 is modified to include a reference to the Ith resource, informationpertaining to such modification is included in the event resource 212.

Thus, the event resource 212 may include an identification of at leastone update (or several low urgency updates) that is available to thefirst client 112. Accordingly, the event resource 212 may include a listof events that identify available updates, a respective type of updatefor an event, and a respective global identifier for the resource beingupdates. Exemplary data included in the event resource 212, then, can beas follows:

Events ID of Resource Updated Update Type Update1/messagingapp/user/contactslist modification Next Event Batch/messagingapp/nextevents new resource

When an update is categorized as being real-time sensitive, it isdesirable for the first client 112 to receive the update as soon aspossible (e.g., in real-time). Thus, when an update is categorized asbeing real-time sensitive by the server 124, the update may be includedin the reply transmitted to the client 112 by the server 124 whenresponding to the hanging request for the event resource 212—thus, theupdate is available to the first client 112 immediately upon the server124 recognizing the update. Similarly, when the event resource 212includes data that indicates that a particular update is categorized asbeing of high urgency, the server 124 can reply to a hanging request forthe event resource 212 with metadata that indicates that the update isavailable to the client 112 (without providing the update itself). Thereply may be delivered to the client 112 through a VoIP socket, forinstance.

Updates categorized as being low urgency, however, need not be deliveredto the first client 112 right away. Instead, identification low urgencyupdates can be aggregated in the event resource 212 for a thresholdamount of time, or until urgency of an update is changed (e.g., from lowurgency to high urgency). Such aggregation can positively impactcommunications between the first client 112 and the server 124. Forexample, if another resource is added and then updated, what may havebeen two separate updates can be aggregated together. Not only can thissimplify processing for the first client 112, as the another resourceneed only be requested and processed once, but also the chattiness ofthe application can be reduced, as multiple requests and/or updates arereduced to a single communication for the aggregated updates.

It can also be appreciated that high urgency and low urgency updates mayalso be embedded into the reply to the hanging request. For example, thesize of an update may be small and would not have a negative impact ontransmitting the reply. In another example, the total number ofavailable updates may be low, such that transmitting the update ratherthan waiting for a request is more efficient.

The reply from the server 124 to a hanging request from the first client112 can include metadata that comprises an indication of a type of theupdate and a global identifier of a resource that has been updated.Exemplary metadata in the form of an XML file that can be transmittedfrom the server 124 to the client 112 when the server replies to ahanging request for the event resource 212, and an update is not areal-time sensitive update, can be as follows:

  <EVENTS>  <UPDATE1>   <ID> /messagingapp/user/contactslist </ID>  <TYPE>modification</TYPE>  </UPDATE1>  <NEXTEVENTSID>/messagingapp/nextevents  </NEXTEVENTSID> </EVENTS>

For updates categorized as being high or low urgency, the first client112 can analyze the reply from the server 124 and identify updates thatare desirably retrieved from the server 124. The first client 112 canthen transmit a request to the server 124 for at least one desiredupdate. Responsive to the request, the server 124 provides the update tothe first client 112.

As noted above, the receiver component 206 of the client 112 receivesthe reply from the server 124, responsive to receipt of the reply, thefirst client 112 transmits an acknowledgment receipt to the server 124.In some instances, this acknowledgment can also comprise another hangingrequest for a next batch of available updates. Because theacknowledgement also comprises a next hanging request, chattiness of thecommunication can be further reduced. As replies transmitted from theserver 124 to the first client 112 (except for replies that includeupdates categorized as being real-time sensitive) include metadata butnot updates, the first client 112 can determine when and how to retrieveupdates, and thus can direct the server 124 to deliver only thoseupdates for which the first client 112 is prepared to receive and/or iscapable of receiving.

The first client 112 can also comprise a decider component 214 that isconfigured to determine a retrieval type for an update identified in areply received from the server 124. The decider component 214 can makesuch determination based at least in part upon at least one of acapability of the first client 112, an urgency of the update, or anetwork traffic condition. For example, the first client 112 may only beable to properly receive a certain amount of data at a time, and thuscannot receive all updates that are available; the first client 112 maybe designed to receive a certain number of updates at a time; or highnetwork traffic may cause communication delays that impact the fidelityof the data or otherwise cause communication problems, bottlenecks, orerrors. The retrieval type can be one of eager retrieval, lazyretrieval, or non-retrieval.

With respect to eager retrieval, the decider component 214 causes theupdate requester component 210 to immediately transmit a request for anupdate identified as being available by the server 124 to the server 124(e.g., a request for the updated first resource 202). When the retrievaltype is lazy retrieval, also referred to as opportunistic retrieval, thedecider component 214 causes the update requester component 210 totransmit a request for an update identified as being available by theserver 124 to the server 124 when a predefined condition is satisfied.The condition may be, for example, when a cost of retrieving the updateis below a threshold; when no other updates or traffic is incoming; whena certain communications speed or bit rate is available between thefirst client 112 and the server 124, etc.

The decider component 214 can also determine that, for a current stateof the first client 112 and/or at a current point in time, the updateidentified in the reply received from the server 124 is not necessary,and no request for the update is made (e.g., the retrieval type isnon-retrieval). The decider component 214, however, can be configured toset a flag to indicate that a particular resource (e.g., the firstresource 202) has been updated, such that when the first client 112determines that the resource is desirably accessed, the first client 112causes the update requester component 210 to transmit a request for theupdate to the resource. Responsive to receiving a request for an update,the server 124 transmits the update to the first client 112.

Referring now to FIG. 3, an exemplary system 300 that facilitatesperforming an asynchronous operation during real-time bi-directionalcommunication between the first client 112 and the server 124 using aRESTlike API is illustrated. The system 300 comprises the first client112 that is in real-time communication with the server 124 using theRESTlike API.

An asynchronous operation can include at least one step to be performedby at least one of the first client 112 or the server 124. For instance,an operation performed by the sever 124 to place a call through a voicecommunications application that can be directed to multiple clientsbefore being accepted or declined may comprise the acts of: 1) receivinga request to make the call from the first client 112; 2) identifying anintended recipient; 3) identifying clients of the intended recipientthat are available to receive the call; and 4) completing the callrequest. The server 124 can be configured to receive/generate anindication that a step in the operation has been performed or has failedto be performed. Further, the operation can be modeled with a frameworkthat can cause intermediate events to be generated. For example, inorder for the first client 112 to understand the status of a call (e.g.,ringing, connected, or failed), events are desirably served to the firstclient 112 that indicate the state of the operation to the first client112.

To that end, the first client 112 comprises the requester component 206,wherein the requester component 206 transmits a request to perform anasynchronous operation to the server 124. Responsive to receiving therequest to perform the asynchronous operation, the server 124 creates anoperation resource 302. The operation resource 302 can be used to modelthe asynchronous operation, and can further be modeled after a dedicatedtransient resource that follows a pattern of started, updated, andcompleted.

The operation resource 302, as has been described above with respect tothe resources 202-204, may be accessed and interacted with usingcommands including methods such as the HTTP methods “GET”, “PUT”, “POST”and “DELETE”. The operation resource 302, however, can also configuredto cause the server 124 to add (in this example) the first resource 202,modify the first resource 202, or delete the first resource 202. Suchadding, modifying, or deleting is based, at least in part, upon a stepin the asynchronous operation. For instance, in an example where thefirst client 112 wishes to make a call to a contact of a user of thesecond client computing device 104, the request can be transmitted tothe server 124, which creates the operation resource 302 responsive toreceiving the request. The operation resource 302 can, for instance,create the first resource 202 to be an “available devices” resource,which comprises data that indicates devices of the contact that arecapable of receiving the call.

The operation resource 302 is also configured to cause the server 124 totransmit events that represent the evolution of states of theasynchronous operation until ultimate success or failure of theasynchronous operation. As the asynchronous operation transitionstowards completion, the operation resource 302 transmits high-urgencyupdates/events to the event resource 212, and the server 124 cantransmit a reply that identifies a high-urgency update to the firstclient 112 as described above. For instance, when the request to make acall has been received by the server 124, the server can causehigh-priority updates to be delivered to the first client 112 in orderto indicate that the call is being made, and that an available device isdetected. Other updates identified by the operation resource 302 caninclude: that the operation is starting; that the operation is inprogress; and that the operation has concluded. Such update types mayalso comprise additional information about the state of the operation.In an example, when the update type is that the operation has concluded,the update type may additionally comprise information that the operationwas, for instance, successful, or that it failed, and reasons forsuccess or failure of the operation.

The operation resource 302 can also cause the first resource 202 to beadded, modified, or deleted from the server 124. The server 124 cancause such an update to the first resource 202 to be transmitted to theevent resource 212 and, like updates from the operation resource 302,the update is categorized as high-urgency. By categorizing updatespertaining to the asynchronous operation as high-urgency, the metadataabout the update is immediately transmitted the first client 112, asdescribed above. Thus, the first client 112 is kept informed about thestate of the asynchronous operation without having to wait for theasynchronous operation to complete.

The client 112 further comprises the update requester component 210 thatis configured to send a hanging request to the server 124 for the eventresource 212, as described above. When appropriate, the server 124generates a reply to the hanging request, in the manner set forth abovewith respect to the description of the system 200 in FIG. 2. Asdiscussed above, the metadata in the reply can indicate that the firstresource 202 has been updated. The update requester component 210 canthen transmit a request for the update of the first resource 202 (e.g.,a request for the updated first resource 202) to the server 124 usingthe RESTlike API. Thus, when the operation resource 302 has caused thefirst resource 202 to be added, modified, or deleted, the first client112 is notified of such an update and may request such update whendesired.

Responsive to the update requester component 210 requesting the updatefor the first resource 202, the server 124 can transmit such update, andthe receiver component 208 of the first client 112 can receive suchupdate (and, accordingly, the first client 112 is updated). It should beunderstood that when the operation resource 302 causes other resourcesto be updated, such as the first resource 202, such updates are servedto the client 112 prior to the asynchronous operation completing,regardless of whether the operation successfully or unsuccessfullycompletes the operation. By doing so, updates to resources are deliveredprior to any dynamic resources associated with the asynchronousoperation being deleted.

FIGS. 4-10 illustrate exemplary methodologies relating to bi-directionalreal-time asynchronous and synchronous communication between computingdevices through use of a RESTlike API. While the methodologies are shownand described as being a series of acts that are performed in asequence, it is to be understood and appreciated that the methodologiesare not limited by the order of the sequence. For example, some acts canoccur in a different order than what is described herein. In addition,an act can occur concurrently with another act. Further, in someinstances, not all acts may be required to implement a methodologydescribed herein.

Moreover, the acts described herein may be computer-executableinstructions that can be implemented by one or more processors and/orstored on a computer-readable medium or media. The computer-executableinstructions can include a routine, a sub-routine, programs, a thread ofexecution, and/or the like. Still further, results of acts of themethodologies can be stored in a computer-readable medium, displayed ona display device, and/or the like.

Referring now to FIG. 4, an exemplary methodology 400 that facilitatesbi-directional real-time asynchronous and synchronous communicationbetween computing devices through use of a RESTlike API is illustrated.The methodology 400 starts at 402, and at 404 a client-side instance ofan application is executed on a client computing device, wherein theapplication supports real-time synchronous communication and real-timeasynchronous communication with a second computing device through use ofa RESTlike API. At 406, the client-side instance communicates, inreal-time, synchronously and/or asynchronously with the server using theAPI. The methodology 400 completes at 408.

Referring now to FIG. 5, another exemplary methodology 500 executed at afirst computing device that facilitates communicating, in real-time,synchronously and synchronously communication with a second computingdevice (using a RESTlike API) is illustrated. The methodology 500 starts502, and at 504, a request for a resource on the server is transmittedto the server, wherein the request comprises a global identifier for theresource. At 506, data pertaining to the resource is received from theserver, wherein the data pertaining to the resource can be an XML file,an update for the resource, etc. The methodology 500 concludes at 508.

Referring now to FIG. 6, another exemplary methodology 600 executed by afirst (client) computing device that facilitates communicatingbi-directional in real-time with a second computing device (e.g., aserver computing device) is illustrated. The methodology 600 starts at602, and at 604, a hanging request comprising a global identifier istransmitted from the client computing device to the second computingdevice, the global identifier identifying a resource on the server. At606, metadata pertaining to an update to the resource is received. Themetadata can identify an update that is available for the resource, orcan include the update for the resource. The methodology 600 completesat 618.

Referring now to FIG. 7, another exemplary methodology 700 executed by afirst (client) computing device that facilitates communicating with asecond (server) computing device, by way of a RESTlike API,bi-directionally, synchronously and asynchronously, and in real-time isillustrated. The methodology 700 begins at 702, and at 704, a hangingrequest comprising a global identifier for a resource is transmitted tothe second computing device, wherein the global identifier identifiesthe resource. At 706, a reply to the hanging request is received fromthe first computing device, wherein the reply includes metadata thatidentifies an available update to the resource. At 708, a retrieval typefor retrieving the update is determined, wherein the retrieval type canbe one of eager retrieval, lazy retrieval, or non-retrieval. At 710, arequest for the update is transmitted to the second computing device inaccordance with the retrieval type determined at 710. At 712, the updateis received from the server, and the methodology 700 completes at 714.

Referring now to FIG. 8, an exemplary methodology 800 that is executedby a first (server) computing device that facilitates bi-directional,real-time asynchronous and synchronous communication between the firstcomputing device and a second (client) computing device by way of aRESTlike API is illustrated. The methodology 800 begins at 802, and at804, a hanging request for an event resource is received, wherein theevent resource is retained in a computer-readable storage medium. At806, the server computing device determines that a resource (other thanthe event resource) has been updated. At 808, data pertaining to theupdate of the resource is sent to the event resource, and at 810, theupdate is categorized as high-urgency. At 812, the server computingdevice transmits a reply to the hanging request to the client computingdevice, the reply comprising metadata that identifies that the update isavailable. At 814, subsequent to the server computing devicetransmitting the reply at 812, the server computing device receives arequest from the client computing device for the update. At 816, theserver computing device transmits the update to the client computingdevice, and the methodology 800 completes at 818.

Referring now to FIG. 9, another exemplary methodology 900, executed ata server computing device, that facilitates bi-directional real-timecommunication between the server computing device and the clientcomputing device is illustrated. The methodology 900 begins at 902, andat 904 a request is received for a resource on the server computingdevice. For instance, the request can include a global identifier forthe resource. At 906, a reply to the request is transmitted to theclient, where the reply comprises a data packet pertaining to theresource (e.g., data formatted in a form that can be parsed by theclient computing device). At 908, a hanging request is received from theclient computing device, the hanging request identifying an eventresource that is used to monitor updates made to the resource. At 912, areply to the hanging request is transmitted to the client, wherein theresponse comprises metadata pertaining to the resource. The methodology900 completes at 914.

Referring now to FIG. 10, an exemplary methodology 1000 executed at aclient computing device that facilitates performing an asynchronousoperation with a server computing device (e.g., through use of aRESTlike API) is illustrated. The methodology 1000 starts at 1002, and1004, a request to perform an asynchronous operation is transmitted tothe server. In an example, the request can cause the server to create anoperation resource for the requested asynchronous operation. At 1006, ahanging request for an event resource transmitted to the servercomputing device. At 1008, for each step of the asynchronous operationrepresented in the operation resource that is performed at the servercomputing device, a respective high-urgency update notification isreceived from the server computing device. At 1010, metadata thatidentifies an available update to another resource is received from theserver computing device. For instance, the available update may be anupdate that caused by a step of the operation being performed. At 1012,a request is transmitted to the server computing device for the update,and at 1014 the update is received at the client computing device. Themethodology 1000 completes at 1016.

Referring now to FIG. 11, a high-level illustration of an exemplarycomputing device 1100 that can be used in accordance with the systemsand methodologies disclosed herein is illustrated. For instance, thecomputing device 1100 may be used in a system that facilitatesbi-directional real-time asynchronous and synchronous communicationusing a RESTlike API. By way of another example, the computing device1100 can be used in a system that facilitates performing an asynchronousoperation using a RESTlike API. The computing device 1100 includes atleast one processor 1102 that executes instructions that are stored in amemory 1104. The instructions may be, for instance, instructions forimplementing functionality described as being carried out by one or morecomponents discussed above or instructions for implementing one or moreof the methods described above. The processor 1102 may access the memory1104 by way of a system bus 1106. In addition to storing executableinstructions, the memory 1104 may also store an instance of theapplication, a local cache, a resource or a representation of aresource, updates, metadata pertaining to updates, or updatenotifications or indications.

The computing device 1100 additionally includes a data store 1108 thatis accessible by the processor 1102 by way of the system bus 1106. Thedata store 1108 may include executable instructions, data or metadatapertaining to executing a client or server of an application, resources,API instructions or methods, etc. The computing device 1100 alsoincludes an input interface 1110 that allows external devices tocommunicate with the computing device 1100. For instance, the inputinterface 1110 may be used to receive instructions from an externalcomputer device, from a user, etc. The computing device 1100 alsoincludes an output interface 1112 that interfaces the computing device1100 with one or more external devices. For example, the computingdevice 1100 may display text, images, etc. by way of the outputinterface 1112.

It is contemplated that the external devices that communicate with thecomputing device 1100 via the input interface 1110 and the outputinterface 1112 can be included in an environment that providessubstantially any type of user interface with which a user can interact.Examples of user interface types include graphical user interfaces,natural user interfaces, and so forth. For instance, a graphical userinterface may accept input from a user employing input device(s) such asa keyboard, mouse, remote control, or the like and provide output on anoutput device such as a display. Further, a natural user interface mayenable a user to interact with the computing device 1100 in a mannerfree from constraints imposed by input device such as keyboards, mice,remote controls, and the like. Rather, a natural user interface can relyon speech recognition, touch and stylus recognition, gesture recognitionboth on screen and adjacent to the screen, air gestures, head and eyetracking, voice and speech, vision, touch, gestures, machineintelligence, and so forth.

Additionally, while illustrated as a single system, it is to beunderstood that the computing device 1100 may be a distributed system.Thus, for instance, several devices may be in communication by way of anetwork connection and may collectively perform tasks described as beingperformed by the computing device 1100.

Various functions described herein can be implemented in hardware,software, or any combination thereof. If implemented in software, thefunctions can be stored on or transmitted over as one or moreinstructions or code on a computer-readable medium. Computer-readablemedia includes computer-readable storage media. A computer-readablestorage media can be any available storage media that can be accessed bya computer. By way of example, and not limitation, suchcomputer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium that can be used to carry or storedesired program code in the form of instructions or data structures andthat can be accessed by a computer. Disk and disc, as used herein,include compact disc (CD), laser disc, optical disc, digital versatiledisc (DVD), floppy disk, and blu-ray disc (BD), where disks usuallyreproduce data magnetically and discs usually reproduce data opticallywith lasers. Further, a propagated signal is not included within thescope of computer-readable storage media. Computer-readable media alsoincludes communication media including any medium that facilitatestransfer of a computer program from one place to another. A connection,for instance, can be a communication medium. For example, if thesoftware is transmitted from a website, server, or other remote sourceusing a coaxial cable, fiber optic cable, twisted pair, digitalsubscriber line (DSL), or wireless technologies such as infrared, radio,and microwave, then the coaxial cable, fiber optic cable, twisted pair,DSL, or wireless technologies such as infrared, radio and microwave areincluded in the definition of communication medium. Combinations of theabove should also be included within the scope of computer-readablemedia.

Alternatively, or in addition, the functionally described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs), etc. The processor module and/or acombination of the processor module and associated memory describedherein is intended to encompass any of such hardware logic components.

What has been described above includes examples of one or moreembodiments. It is, of course, not possible to describe everyconceivable modification and alteration of the above devices ormethodologies for purposes of describing the aforementioned aspects, butone of ordinary skill in the art can recognize that many furthermodifications and permutations of various aspects are possible.Accordingly, the described aspects are intended to embrace all suchalterations, modifications, and variations that fall within the spiritand scope of the appended claims. Furthermore, to the extent that theterm “includes” is used in either the details description or the claims,such term is intended to be inclusive in a manner similar to the term“comprising” as “comprising” is interpreted when employed as atransitional word in a claim.

What is claimed is:
 1. A computing device comprising: a processormodule; and a memory that comprises a client-side instance of anapplication, the client-side instance of the application executed by theprocessor module, the application supporting real-time synchronouscommunication and real-time asynchronous communication between thecomputing device and a second computing device using an applicationprogramming interface (API) that is compliant with to a representationalstate transfer (REST) architecture.
 2. The computing device of claim 1,the client-side instance of the application comprising: a requestercomponent that transmits a request to the second computing device usingthe API, the request comprising a global identifier for a resource; anda receiver component that receives a reply from the second computingdevice that is based upon the request, the reply comprising at least oneof a representation of the resource, an update to the resource, ormetadata for the resource.
 3. The computing device of claim 2, whereinthe resource comprises a global identifier of another resource.
 4. Thecomputing device of claim 1, the client-side instance of the applicationfurther comprising: an update requester component that transmits ahanging request to the second computing device for an event resource,the event resource comprising data pertaining to an update to a resourcemaintained by the second computing device, the hanging requestcomprising a global identifier for the event resource; and a receivercomponent that receives a reply to the hanging request, the replycomprising metadata based upon the data included in the event resource,the metadata comprising an indication of a type of the update and aglobal identifier for the resource.
 5. The computing device of claim 4,wherein metadata further comprises the update.
 6. The computing deviceof claim 4, wherein the reply fails to comprise the update, and theclient-side instance of the application further comprising a decidercomponent that determines a retrieval type for the update based at leastin part upon at least one of a capability of the computing device, anurgency of the update, or a network traffic condition, the decidercomponent causes the update requester component to transmit the hangingrequest based upon the retrieval type.
 7. The computing device of claim6, the retrieval type being eager retrieval, wherein the decidercomponent causes the update requester component to immediately transmita request for the update.
 8. The computing device of claim 6, theretrieval type being lazy retrieval, wherein the decider componentcauses the update requester component to transmit a request for theupdate when a benefit of retrieving the update is below a threshold. 9.The computing device of claim 6, the retrieval type being non-retrieval,wherein the decider component fails to cause the update requestercomponent to transmit a request for the update.
 10. The computing deviceof claim 4, wherein the type of the update is one of an addition of theresource on the second computing device, a modification of the resource,or a deletion of the resource from the second computing device.
 11. Thecomputing device of claim 1, the client-side instance of the applicationfurther comprising a requester component that transmits a request toperform an asynchronous operation to the second computing device usingthe API, wherein the request is configured to cause the second computingdevice to create an operation resource on the second computing device,the operation resource usable to update a resource on the secondcomputing device based upon at least one step of the asynchronousoperation, the operation resource further usable to cause the secondcomputing device to update an event resource on the second computingdevice.
 12. The computing device of claim 1, the first computing devicebeing on of a mobile telephone or a tablet computing device.
 13. Thecomputing device of claim 1, wherein the real-time asynchronouscommunication is at least one of a file transfer, an electronic message,an event scheduling request, a presence indication, an update to acontacts list, or an update to a groups list.
 14. The computing deviceof claim 1, wherein real-time synchronous communication comprises atleast one of video stream, a video conference, a voice communication, ordata pertaining to application sharing.
 15. A method executed by aprocessor module of a computing device, the method comprising: executinga client-side instance of an application that supports real-timesynchronous communication and real-time asynchronous communicationbetween the computing device and a second computing device by way of anapplication programming interface (API) that is compliant with arepresentational state transfer (REST) architecture; and asynchronouslyand/or synchronously transmitting and receiving data in real-time by wayof the application.
 16. The method of claim 15, wherein asynchronouslyand/or synchronously transmitting and receiving data in real-time by wayof the application comprises: transmitting a request to the secondcomputing device by way of the API for a resource, the requestcomprising a global identifier for the resource; and receiving a replyto the request from the second computing device, the reply comprising atleast one of a representation of the resource, an update to theresource, or metadata for the resource.
 17. The method of claim 15,further comprising; transmitting a hanging request for an event resourceto the server by way of the API, the event resource comprisinginformation pertaining to an update to a resource, the requestcomprising a global identifier of the event resource; and receiving areply to the hanging request from the second computing device by way ofthe API, the reply comprising metadata that is based upon theinformation, the metadata comprising an indication of a type of theupdate and a global identifier for the resource.
 18. The method of claim17, the method further comprising: determining a retrieval type forretrieving the update based at least in part upon at least one of acapability of the computing device, the application, a network trafficcondition, or an urgency of the update; and retrieving the update inaccordance with the retrieval type, wherein the retrieval type is one ofeager retrieval, lazy retrieval, or non-retrieval.
 19. The method ofclaim 15, the computing device being a mobile telephone.
 20. A computerreadable data storage device comprising instructions that, when executedby a processor, cause the processor module to perform acts comprising:executing a client-side instance of an application that supportsreal-time synchronous communication and real-time asynchronouscommunication between the computing device and a server using anapplication programming interface (API) that complies with arepresentational state transfer (REST) architecture, wherein executingthe client side instance of the application comprises: transmitting arequest to the server for data pertaining to a resource, the requestcomprising a global identifier for the resource, wherein the resourcecomprises data and a global identifier of a second resource; receiving adata packet that is based upon the resource, wherein the data packet isin one of an XML or a JSON format; transmitting a request to the server,the requesting comprising a global identifier for an event resource, theevent resource comprising information pertaining to an update for theresource; and receiving the update for the resource responsive totransmitting the request to the server, the update for the resourcebeing identified as a real-time sensitive update.